Recap

• A remote is repository hosted elsewhere than your local machine (e.g., on GitHub)
  • The remote is named origin or upstream.
  • On GitHub a remote URL looks like
    • https://github.com/OWNER/REPO.git or
    • git@github.com:OWNER/REPO.git

Recap

Recap

Recap

• A fork is a copy of a repository on a remote server (e.g., GitHub)
• A clone is a copy of a repository on your local machine

No GitHub

Yours

Yours - setup

• If the local repo exists first:
  • For detailed instructions see Existing project, GitHub last.
  • usethis::use_github().
  • Command line/RStudio: Task can’t be completed fully (see Chapter 25.2)
• If the remote repo exists first:
  • For detailed instructions see New RStudio Project via git clone.
  • usethis::create_from_github("OWNER/REPO", fork = FALSE).
  • Command line: git clone <URL>
  • RStudio: File > New Project > Version Control > Git

Ours

Theirs

Fork (of theirs)

Fork (of theirs) - setup

• Detailed instructions are given in Fork and clone.
• usethis::create_from_github("OWNER/REPO", fork = TRUE).
• Command line Git or RStudio: You can’t complete this task fully

Fork (of ours)

Fork (salvageable)

Recap

• A commit is a snapshot of your project at a particular point in time.
  • It captures changes made to files and records them in the version history.
  • git commit
• Amend is used to rewrite the last commit (e.g., update commit message or files).
  • git commit --amend
  • Allows fixing minor issues without creating a new commit

Mountain Climbing Analogy

Mountain Climbing Analogy

Mountain Climbing Analogy

Mountain Climbing Analogy

When to Use Amend

• If you made a minor error or forgot to add files
• If you need to update the commit message
  • git commit --amend
  • RStudio makes it very easy

Potential Pitfalls

• Amending after pushing:
  • You should avoid amending commits that have already been pushed to a shared repo
  • Amending pushed commits rewrites history and can cause problems for collaborators
  • Use with caution when working on shared repositories

Workflow - Step 1

Start with your project in a functional state.

• Use git status to check this.

Workflow - Step 2

Initial status of project.

Workflow - Step 2

Make a small change towards a larger objective and commit it as WIP (work in progress)

git commit -m "WIP"

Workflow - Step 2

• Do a bit more work.
• Re-check that your project is still in a functional state.
• Stage and commit again, with amended commit: git commit --amend --no-edit

Workflow - Step 2

• Keep going until you’ve achieved your final objective.
• Now amend the commit, but add a real message

git commit --amend -m "Implement awesome feature"

Workflow - Step 3

What if you make some changes that break your project?

A -- B -- C -- WIP* 

• You want to fall back to the last good state, represented by WIP*.
  • This is called a hard reset to the WIP* state.
  • Meaning: “reset my files to their state at the most recent commit”.

Workflow - Step 3

How to achieve?

• command line: git reset --hard
• RStudio:
  • Click on “Diff” or “Commit”.
  • Select a file with changes you do not want.
  • Use “Discard All” to discard all changes in that file.
  • Use “Discard chunk” to discard specific changes in a file.

Workflow - Step 4

Let’s imagine you pushed this state to GitHub by mistake:

A -- B -- C -- WIP (85bf30a)

A -- B -- C -- WIP* (6e884e6)

Workflow - Step 4

You have two choices:

1. You’re working with collaborators:

• Save a copy of any files that exist locally (with changes) to a new file path, temporarily.
• Hard reset your local repo to C (git reset --hard HEAD^) and pull from GitHub.

A -- B -- C -- WIP (85bf30a)

• Bring any files saved temporarily elsewhere back into the repo now; save, stage, commit, and push.

A -- B -- C -- WIP (85bf30a) -- E

Workflow - Step 4

You have two choices:

2. You have no collaborators:

• Make sure your local commit has a real, non-“WIP” message.
• Force push your history to GitHub (git push --force).

A -- B -- C -- D

Problem

Our push is rejected!

$ git push
To https://github.com/YOU/REPO.git
 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'https://github.com/YOU/REPO.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Solve the mystery

Use git status to figure out where the divergence has occurred.

A -- B -- C

A -- B -- D

Fix the problem

To reconcile the differences:

1. Pull the commit C (git pull)
2. Integrate the changes in C into your D-containing history.
3. Push again (git push)

A -- B -- C -- D

Lessons

1. She who pushes first wins!

• It is better for the overall health of a project to commit, push, and integrate more often, not less.

2. Stay in touch

• The sooner you know about C, the better. Pull (or fetch) often.

3. Use branches

• Branches afford explicit workflows for integrating different lines of work on your own terms.

Problem

You want to pull upstream changes but have made local commits or uncommitted changes.

• Remote: A--B--C
• Local: A--B--D

Case 1: Local Work is Uncommitted

Scenario:

• Remote: A--B--C
• Local: A--B--(uncommitted changes)

                 Remote: A--B--C

Local before 'git pull': A--B--(uncommitted changes)
 Local after 'git pull': A--B--C--(uncommitted changes)

Case 1: Local Work is Uncommitted

git stash works, sometimes

• Your changes affect a file that has also been changed in commit C.
• git pull won’t work

git stash save
git pull
git stash pop

Case 1: Local Work is Uncommitted

git stash with conflicts

• If the changes overlap, you’ll get a conflict message when using git stash pop
• You must resolve the merge conflict.
  1. At each locus of conflict, pick one version or the other (upstream or stashed) or create a hybrid yourself.
  2. Remove the all the markers inserted to demarcate the conflicts.
  3. Save.

Case 1: Local Work is Uncommitted

git stash with conflicts

• Since git stash pop did not go smoothly,
  • we need to manually reset git reset
  • and delete the stash git stash drop

Case 2: Local work is committed

Scenario:

• Remote state is A--B--C.
• Local state is A--B--D.

• The simplest option is to fetch the commits from upstream and merge them
  • this is what git pull does
• If there are no conflicts, we’re done!

Case 2: Local work is committed

• If commit C (on the remote) and commit D (local) have changes to the same parts of one or more files, this will result in a merge conflict.

jenny@2015-mbp ethel $ git pull
Auto-merging foo.R
CONFLICT (content): Merge conflict in foo.R
Automatic merge failed; fix conflicts and then commit the result.

• You must resolve each conflict before continuing.

Case 2: Local work is committed

jenny@2015-mbp ethel $ git add foo.R
jenny@2015-mbp ethel $ git commit
[main 20b297b] Merge branch 'main' of github.com:jennybc/ethel

      Remote: A--B--C

Local before: A--B--D
 Local after: A--B--D--(merge commit)
                  \_C_/

Case 2: Local work is committed

Pull and rebase

• git pull --rebase creates a nicer history than git pull when integrating local and remote commits.
  • it creates a less cluttered commit history
  • can lead to more difficult to resolve merge conflicts

      Remote: A--B--C

Local before: A--B--D
 Local after: A--B--C--D

• Jenny’s rec for beginners: use git pull

Case 3: Other approaches

Scenario:

• Remote state is A--B--C.
• Local state is A--B--(uncommitted changes).

1. Create a new, temporary branch
2. Commit your uncommitted changes there
3. Checkout main and git pull to get changes from upstream
4. Recover the work from the commit in the temporary branch.

1. Merge the temporary branch into main.
2. Cherry pick the commit from the temporary branch into main.